NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/9345

Internet Message Format | 1996-08-05 | 7.8 KB

Path: newshost.lanl.gov!tanmoy
From: [e-mail] (Tanmoy Bhattacharya)
Newsgroups: comp.lang.ada,comp.lang.c
Subject: Re: C/C++ knocks the crap out of Ada
Date: 09 Mar 1996 16:52:53 GMT
Organization: Los Alamos National Laboratory
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]> <4gaa6l$[e-mail]>
    <4gd94r$[e-mail]> <[e-mail]>
    <[e-mail]>
    <4h4j31$[e-mail]>
    <[e-mail]>
    <4hf485$[e-mail]>
    <[e-mail]> <4hq7q4$[e-mail]>
NNTP-Posting-Host: qcd.lanl.gov
Mime-Version: 1.0
Content-Type: text
In-reply-to: [e-mail]'s message of 8 Mar 1996 21:11:32 GMT

In article <4hq7q4$[e-mail]>
[e-mail] (Norman H. Cohen) writes:
<snip>
NHC: |> This is the only mistake in your post:
NHC: |>
NHC: |> The standard requires a diagnostic whenever any constraint or syntax
NHC: |> rule is violated. (5.1.1.3). After diagnosing the error, it can do
NHC: |> whatsoever it pleases.
NHC:
NHC: I think ANSI ripped me off!  I paid them $60 for a copy of the C
NHC: standard, and the one they sent me only goes up to Section 4. :-)
NHC: (Or perhaps there's a typo in your citation? Please clarify.)

ISO adopted ANSI standard with sections renumbered. ANSI adopted the
ISO standard back, so that now section numbers are unambiguous
again. Unfortunately, many people still use the older numbers, so
there is possibility of confusion.

5.1.1.3 is probably 2.1.1.3.

NHC:
NHC: |> In fact, sometimes vendors deliberately want something to invoke
NHC: |> `undefined' behaviour instead of violating a constraint, so that they
NHC: |> can provide an extension that does not need a diagnostic. Some of them
NHC: |> (e.g. $ in a macro name) even get accepted. But, by and large, a
NHC: |> compiler cannot silently compile these category of errors.
NHC:
NHC: I don't understand how this can be reconciled with your previous
NHC: statement.

C makes a distinction between mistakes that must be diagnosed and
those that may be diagnosed. The former category includes all syntax
errors and violation of any requirement specifically set forth in a
`constraints' section in the standard. The latter are violations of
requirements which are mentioned elsewhere. Such violations, along
with all behaviour specifically listed as being in the same category,
as well as constructs for which no meaning can be deduced from the
standard constitute `undefined' behaviour.

Thus unless an implementation wants to present the user with a
diagnostic, an extension cannot violate a constraint: it may violate
other requirements in the standard.

Most, but not all, of the cases where a requirement is put outside a
constraint section; the violation cannot be deduced by a static
analysis of the code (or rather, not easily). Requirements in the
constraints section never need run-time checks.

<snip>
NHC:
NHC: |>           Heck, my theory is more likely to be wrong than my
NHC: |> programming;
NHC:
NHC: Either you're a much  better programmer than most of us or you have a
NHC: very poor track record as a theoretician.

I wouldn't be much of a theorist if I couldn't recognize garbage when
I saw it :-) Programming bugs hardly ever stay till the end. (On the
other hand, you might argue it is only what I believe.)

And by the way, from my experience, the most common kind of errors are
not those that can be statically or dynamically `checked'. I did
occasionally have off by one errors leading to array bound violations,
but, by far, the more important kinds of errors were what one would
call `logic errors'. What I wrote made sense, and probably would have
made sense in every language I expressed myself, but it was not what I
wanted to code. (I actually went through my SCCS tree of the C part of
my current project: except for one case, every non-logic error was
corrected within two days of the mod that introduced the bug in the
first place. I am guessing, but cannot be absolutely certain that this
is because I sometimes take a few days to complete a certain set of
mods before trying to compile and check the code.)

I am not speaking against safety. Now that you have clarified that the
run time checks can be switched off (and that that does not count
as an extension which is completely disallowed :-), I have nothing
against Ada. If I found a compiler I liked on the machine I am
currently working on (CM5 by TMC), I will probably give it a
try.

NHC:
NHC: |>              and I would rather write my code in a `manifestly
NHC: |> correct' way and thoroughly check my code (and cross check it);
NHC:
NHC: Typical programming problems can be solved in either a "manifestly
NHC: correct" but slow way, or in a more obscure but faster way.  What you
NHC: seem to be saying here is that you are willing to sacrifice performance
NHC: for the sake of greater confidence in the correctness of your prrogram.

No. There is a third way:
  break up the code into manageable chunks.
  code each part in a slow way
  profile the code
  rewrite the chunks that are important to be as fast as one needs
  test the slow chunk against the fast chunk with random input with
    only one property: it satisfies the _documented_ precondition
    of the chunk. (In particular, the random input often violates a
    lot of assumptions which will hold during the actual run, but
    which do not open up any significant optimization opportunities.)
  leave the slow and fast versions of the code around, along with the
    tester code: this triplet forms the reusable unit for this chunk.

It usually means more effort to write the code, but I do not think
that switching languages will significantly alter this habit. As you
can see this leads to optimized code, so there is no conflict with the
following statement.

It is possible that someday I will meet code which can be optimized
only when one treats the problem as a whole (i.e. optimization of the
parts would lead to a significantly slower code than optimizing the
entire code into an obscure mess), but I really haven't met such
problems.

NHC: But then you continue:
NHC:
NHC: |>                                                                 than
NHC: |> write in a language that will check every operation that I do. I
NHC: |> typically code for 3 months human time, and run for 1 year's cpu time:
NHC: |> I do not really care if that 3 months become four, but I can't afford
NHC: |> the 1 year becoming 13 months!
NHC:
NHC: Even if we accept that using C instead of Ada only increases your
NHC: development and debugging time by 33%, and that using Ada instead of C
NHC: increases the execution time of your program by 1/12, I find it hard to
NHC: understand why it is okay for your 16 months to be split 4+12, but not
NHC: 3+13, especially since 3+13 gives you a program in whose correctness you

Because I pay for the 13, and I am paid for the 4 :-)

<snip>
NHC: fail), or are not expensive enough to worry about.  Many programs,
NHC: particularly scienitific programs, can be sped up significantly by
NHC: suppressing checks in a few small critical inner loops, which can be
NHC: scrutinized especially carefully.  The remaining checks contribute very
NHC: little to the overall running time of the program.

Correct.

Cheers
Tanmoy
--
[e-mail](128.165.23.46) DECNET: BETA::"[e-mail]"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: [phone]   voice: 1 [phone]    [ Home: 1 [phone] ]